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REMARKS 

Claims 2 through 9, 11 through 25, 27 through 30 and 38 through 57 were rejected 
under 35 U.S.C. § 102(e) as anticipated by Sahai eta/. Claim 2 has been amended. Claim 2 
now provides that the quality of encoding includes a first quality and a second quality where the 
first quality is less than the second quality. Claim 2 also includes the step of selecting either the 
first quality or the second quality based on the type of content of the audio image and video. 
The Examiner cites Sahai at column 3, lines 23-60, as indicating the attributes of the preference 
description. However, this passage in Sahai does not provide the claimed preferences 
description with media attributes wherein the attribute describes the quality of encoding. At 
line 50, quality of service is listed as one of the pieces of data sent by the client to the server 
but there is no media attribute that the system provides as parts of the preferences description 
that describes the quality of encoding of audio image or video. Moreover, claim 2 now includes 
the step of selecting an image, audio or video, of either a first quality or a second quality of 
encoding based upon the type of content . Sahai teaches only that the server adjusts the 
quality of media based upon the capabilities of the client. By contrast, claim 2 now requires 
that the system include user preferences that select the quality of encoding based on the type 
of content - for example, a higher bit rate for sports content than for nature content. 

Claim 21 requires that the system receive a broadcast of audio or video and that it 
include a storage device. Further, the claim specifies that the system encode the broadcast at 
one of a plurality of different qualities for storage on the storage device. The Examiner cites 
column 6, lines 50-52, of Sahai for support for the storage device limitation. However, this 
paragraph from Sahai says only that the process for adapting the data stream is stored. 
Moreover, it is stored on the server 10 and not on the client device. Sahai teaches only 
transmission of data (streaming) and does not show storage of differently encoded media on a 
storage device. The server 10 accesses a file that is stored on the server that includes client 
capabilities but this does not indicate the amount of storage space available on the client as 
stated, for example, in claim 23. Contrary to the Examiner's assertion, column 5, lines 35-46, 
and column 6, lines 12-49, say nothing about encoding based upon the type of content 
specified by user preferences. Sahai is concerned only with the system capabilities of the user. 
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Claims 22 through 30 are dependent on claim 21 and thus, like claim 21, are patentable over 
Sahai. 

With respect to claim 38, as stated with respect to claim 2, Sahai does not encode audio 
or video based upon its content. Encoding at the transmission end of Sahai's system is based 
solely on user capabilities. These are only hardware and software attributes - not user choices 
based upon content. Further, in Sahai, there is no "storage attribute" provided as part of the 
user preferences description because Sahai provides no storage for media received by the user. 

With respect to claim 49 as stated above in connection with the discussion as to claim 
38, Sahai provides no storage attribute as part of a user preferences description. 

With respect to claim 57, the same arguments as above apply. In addition, Sahai does 
not teach an "agent" that selects the quality of encoding based upon prior selections. Sahai 
teaches encoding based only upon system capabilities that are accessed in a file on the client 
device (column 5, lines 7-10): The media player on the client machine determines the MIME 
type. In Sahai, there are no "prior selections of either a first quality and said second quality." 
There is only one quality in Sahai once the media player and client capabilities are known. The 
rejection under 35 U.S.C. § 102(e) with respect to Sahai should be withdrawn as claims 2, 21, 
38, 49 and 57 and any claims dependent thereon. 

Claims 10, 26, 31 through 37, and 94 through 103 were rejected under 35 U.S.C. § 103 
as being unpatentable over Sahai in view of Li etaL To begin with, these claims all require the 
step of storing all or a portion of the media broadcast by the system or require a storage 
attribute. Claim 31, for example, requires the step of providing a storage attribute of the user 
preferences that describes the quality of encoding audio or video during a system pause in 
viewing or listening. Claim 10 requires storing a portion of audio or video as does claim 26. 
Claim 94 does not require storage perse but does require a mode attribute that permits a 
forward speed, a reverse speed and a time interval-skipping feature. With respect to all of the 
above except for claim 94, neither Sahai nor Li, either singly or in combination, provides such a 
storage feature. Sahai provides no "storage attribute" as part of a user preferences description. 
In fact, in Sahai's system, there is no storage at the client end of the system. Thus, there can 
be no storage attribute describing the user's audiovisual system. Further, there is no teaching 
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in either Li or Sahai that any storage attribute is provided which describes the quality of 
encoding while the system pauses. Li provides a pause function but does not describe the 
quality of encoding on a data storage unit. Sahai has no data storage unit with attributes 
defined by a user preferences description. Li is a video on demand system that does not 
contemplate storage of media and thus does not provide for differences in encoding as part of a 
user preferences description. Thus even if it were assumed to be proper to combine Sahai and 
Li under § 103, such combination would fail to contain the features of the above-recited claims. 

Further, the combination of Li and Sahai is improper under an obviousness analysis. 
Sahai is a system that transmits media according to a) the capabilities of the user's system, and 
b) user preferences such as CPU processing power and other attributes listed at column 3, lines 
23-60. Sahai has no provision for pausing the transmission of data because it lacks the 
synchronized buffer capability of Li. To properly combine Sahai and Li, one would have to 
assume that Sahai could be modified to include Li's "on demand" and interactive features which 
require these types of buffers. However, this is unworkable in Sahai because Sahai's system 
must adapt to different user profiles. In Li, the interactive features work because there are no 
different equipment profiles - each user has the same receiver box. Thus, the two systems are 
fundamentally incompatible and one of ordinary skill in the art would not have assumed that Li's 
functionality could be somehow imported into Sahai's system. Thus, the rejection of these 
claims under § 103 should be withdrawn. 

Claims 61 through 72 were rejected under 35 U.S.C. § 103 as unpatentable over Sahai 
in view of Fano. The Examiner acknowledged that Sahai did not provide a time delivery 
preference. The Examiner suggested that Fano met such preference and it would have been 
obvious to incorporate such a feature into Sahai. However, given the structure of Sahai, it is 
not possible to provide a time delivery preference in Sahai's system. The delivery process of 
Sahai is initiated by accessing a URL. This is a manual operation initiated by the user. Sahai 
requires the Internet for establishing a communications link between the server and the client 
and teaches that the system is triggered by the user clicking on a URL in his browser. By 
contrast, Fano is a video system that does not use the Internet but uses a dedicated network 
with a user at one end and a broadcaster at the other. The two systems are so different that 
the time attribute feature of Fano could not be used in Sahai. Sahai's entire premise is that the 
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user decides when to access the desired media by choosing a URL. The media is not delivered 
at scheduled times but is available immediately whenever the user decides to access it. Thus, it 
would require substantial redesign of the Sahai system to incorporate a feature like Fano's time 
preferences, but such feature would be entirely unnecessary. It makes no sense because the 
data is available in Sahai any time the user desires it. 

Fano further describes an agent that is a program that includes, among other things, 
time delivery preferences of a user. However, this agent apparently "learns" this data by 
monitoring a user's historical usage pattern. Nowhere in Fano's system is there the step of 
providing a time attribute in the preferences description that describes a first (start) time or a 
second (end) time that bears a relationship to a "schedule time." Thus, even if the combination 
of Fano and Sahai were proper, it would not teach what is claimed. 

Claims 73 through 93 were rejected as obvious over Sahai in view of Barrett. This 
rejection is traversed because Barrett does not show a layer attribute in a user preferences 
description. Contrary to the Examiner's assertion, neither Fig. 4A nor Fig. 4B or column 6, lines 
1-27 or 43-58, teach this feature. The discussion in column 6 of Barrett describes groups of 
transcoders that convert one type of information encoding to another, for example, HTML to 
VOXML. Such grouping has nothing to do with layers of supplemental data auxiliary to audio or 
video media. Furthermore, the object of Barrett is do different from what Sahai purports to 
teach that there would be no purpose in using any technique taught by Barrett in the Sahai 
system. Barrett is a system for managing a group of transcoders. Sahai is a system that 
delivers data over the Internet or some other network customized to the capabilities of a client 
device. The "sublayer" described at lines 43-58 of Barrett is a program like a browser that 
caches transcoding steps. It is not, as the claims require, an attribute of audio or video that is 
found in a user preferences description. 

With respect to claim 80, Sahai does not teach a storage device for received audio or 
video and thus does not receive a selected number of layers of supplemental data. Moreover, 
Barrett does not teach layers of data supplemental to audio or video media. 

With respect to claim 89, Barrett does not teach the steps of either providing content or 
type attributes nor of determining the number of layers of supplemental data based upon such 
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content or type attributes. Instead, Barrett encodes files from one format to another, for 
example a .GIF image transferred to a PDF format with a JPEG embedded image. This is 
completely different from what is claimed in claim 89. 

Claims 104 through 107 were rejected as unpatentable over Sahai in view of Huang. 
The claims as amended now include the limitations of cancelled claims 105 through 107. Sahai 
and Huang combined fail to show the step of providing a media attribute which describes the 
user's preferences which include at least one of six audio formats and either letterbox or 4:3 
ratio for video. Huang merely classifies data as audiovisual information but does not describe 
the claimed formats. Claim 104 as amended should thus be allowed. 

Claims 108 through 118 were rejected as obvious in view of Sahai and Kanevsky. This 
rejection is respectfully traversed. It would not have been obvious to combine Kanevsky with 
Sahai because Sahai does not suggest any user preference data related to content as discussed 
previously. Sahai determines user capabilities for receipt of broadcast media and stores these 
in a file accessible by the server. There is no suggestion in Sahai of having user preferences 
with any attributes relating to type, content or other creative attributes that may be desired by 
the user including creation date and the related creative content data set forth in claims 109 
through 118. Kanevsky is a graphical user interface that organizes desktop icons in a fractal 
appearance to preserve screen space and to suggest links between content. Thus, there is no 
motivation to combine Kanevsky with Sahai because Sahai does not suggest a graphic interface 
that contains any data relating to content or creative attributes such as creation date. Sahai's 
user preferences only relate to the capability of a client's machine to receive and display data 
from the server. Accordingly, the rejection should be withdrawn and claims 108 through 118 
should be allowed. 

In view of the above amendments and applicant's arguments, applicant respectfully 
requests that the claims be allowed and the case passed to issue. 

Respectfully submitted, 

Geny, Reg. No. 3^,444 
Tel No.: (503) 227-5631/ 
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